home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 784 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.7 KB  |  92 lines
  1. Path: chronicle.mti.sgi.com!austern
  2. From: sdouglas@armltd.co.uk (scott douglass)
  3. Newsgroups: comp.std.c++
  4. Subject: Bit-field specification incomplete?
  5. Date: 19 Mar 1996 09:47:31 PST
  6. Organization: Apple Computer, Inc.
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <sdouglas-1903961604090001@193.131.176.202>
  9. NNTP-Posting-Host: isolde.mti.sgi.com
  10. X-Original-Date: Tue, 19 Mar 1996 16:04:09 +0000
  11. X-Newsreader: Yet Another NewsWatcher 2.0.2
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBVAwUBMU7zSUy4NqrwXLNJAQFU8wIAg7hj7IOGQ6NNYDZ3fCsAO/j4uktLRG/3
  14.     OjwPEIAHtXTw2SZhEnmzb0+Kx4hJz9BbLfA/8R8Gw3eknLLEvo2z0g==
  15.     =F6O3
  16. Originator: austern@isolde.mti.sgi.com
  17.  
  18. Hello,
  19.  
  20. I was surprised to find that section 9.6, Bit-fields, does not prohibit
  21. 'struct T { int i:-1; };' or 'struct T { int i:0; };' which are constraint
  22. violations in the C standard.  It also does not explicitly state that the
  23. member must act as an integer of the specified numbers of bits.  As it
  24. stands I think a compiler can ignore the width specification entirely
  25. except that it must prevent the address of the field from being taken and
  26. prevent references to the field.  [I'm assuming the phrase "shall not"
  27. means a program that tries to do so is ill-formed.]
  28.  
  29. Should this be fixed?
  30.  
  31. [The rest of this seems pretty archane, even to me but it seems like the
  32. answers should be in the standard.]
  33.  
  34. Since the draft says nothing specifically about the type of a bit-field
  35. member, I assume that it is the type of the member ignoring the bit-field
  36. specifier.  [Although in section 7.2,  Enumeration declarations, it says
  37. "The underlying type of an enumeration shall not be a bitfield." implying
  38. that there is such a thing as a bit-field type.]  So given,
  39.  
  40. enum E { k0, k1, k2 };
  41. struct T { bool b:2; char c:2; short s:2; int i:2; long l:2; E e:2; };
  42.  
  43. void g(bool);
  44. void g(char); void g(unsigned char); void g(signed char);
  45. void g(short); void g(unsigned short);
  46. void g(int); void g(unsigned int);
  47. void g(long); void g(unsigned long);
  48. void g(E);
  49.  
  50. void f(const T* t)
  51.    {
  52.    g(t->b);  // calls g(bool);
  53.    g(t->c);  // calls g(char);
  54.    g(t->s);  // calls g(short);
  55.    g(t->i);  // calls g(int);
  56.    g(t->l);  // calls g(long);
  57.    g(t->e);  // calls g(E);
  58.    }
  59.  
  60. [And so on for 'unsigned char', 'signed char', 'wchar_t', 'unsigned
  61. short', 'short', 'unsigned int' and 'unsigned long'.]
  62.  
  63. Is this correct?  Or does the type of a bit-field depend on the
  64. implementation-defined signedness of bit-fields?  If so, then on an
  65. unsigned plain bit-field machine I would imagine the type of 't->i' above
  66. would be 'unsigned int' but what is the type of 't->c' -- 'char' or
  67. 'unsigned char'?
  68.  
  69. [Are there 'unsigned wchar_t' or 'signed wchar_t'?  I don't think so, but,
  70. section 3.9.1, Fundamental Types, does not explicitly prohibit them as it
  71. does for 'bool' and does not explicitly allow them as it does for 'char'.]
  72.  
  73. Finally, the promotion of a bit-field is specified in 4.5, Integral
  74. promotions.  It specifies that all non-enum bit-fields promote to 'int' or
  75. 'unsigned int'.  This seems wrong for 'long' and 'unsigned long'
  76. bit-fields.  Why should they "promote" to 'int' or 'unsigned int'?  I
  77. would expect a bit-field of type 'long' to have type 'long' or 'unsigned
  78. long' even if the width is short enough to fit in an 'int'.  After all, a
  79. bit-field of enum type where the enum range is too big for 'unsigned int'
  80. promotes to 'long' or 'unsigned long' even if the width is short enough to
  81. fit in an 'int'.
  82.  
  83. Thanks,
  84.     --scott
  85. ---
  86. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  87.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  88.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  89.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  90.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  91. ]
  92.